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Thank  you  for  that  warm  introduction.  (Bill  Collier,  Chairman)  And 
thank  you  for  the  invitation  to  speak  here  today. 

I  am  particularly  struck  by  your  theme;  “Meeting  the  technology 
needs  of  the  warfighter  in  the  year  2000  and  beyond”  because  clearly  this  is 
the  mission  of  my  own  organization.  And  looking  to  how  we  meet  future 
warfighting  needs  with  technology  is  certainly  critical  for  us. 

Environment 


You  know,  meetings  such  as  this  provide  us  an  opportunity  to  look 
to  the  future  and  I  want  to  do  that  with  you.  Charles  Kettering  said  we 
should  all  be  concerned  about  the  future  because  we  will  have  to  spend  the 
rest  of  our  lives  there.  What  the  future  has  in  stock  for  us  will  depend 
largely  on  what  we  place  in  stock  for  the  future.  The  worst  thing  about  the 
future  is  that  it  gets  here  faster  than  it  used  to. 

In  1789,  George  Washington  took  eight  days  to  travel  the  distance 
from  his  home  in  Mount  Vernon  to  the  scene  of  his  inauguration  in  New 
York  City.  The  eight  days  in  itself  is  not  significant.  The  important  fact  is 
that  this  is  the  same  amount  of  time  that  it  would  have  taken  to  travel  that 
distance  1000  years  before.  There  was  no  real  progress  in  transportation  in 
20  centuries — since  Moses  or  Nebuchadnezzar.  Julius  Caesar  could  have 
stepped  from  the  first  to  the  19*'’  century  more  easily  than  Ben  Franklin  into 
the  next.  Now,  for  the  first  time  in  history,  no  man  dies  in  the  same  epoch 
in  which  he  is  born. 

Understanding  the  future  has  always  been  central  to  warfighting 
strategy.  Soviet  Major  General  Sergei  Kozlov  said  that  “the  most  significant 
task  of  military  science  has  always  been  defining  the  character  of  future 
war.  ” 
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If  we  think  back  to  when  the  Victorian  era  came  to  a  close  and  the 
20th  Century  came  into  view,  would  our  predecessors  have  foreseen  that  in 
less  than  a  single  generation  the  greatest  war  in  history  would  break  out? 
Would  they  have  they  anticipated  that  in  less  than  a  single  short  career,  they 
would  see  the  emergence  of  the  airplane,  the  tank,  the  submarine  and  the 
wireless  radio  —  systems  that  would  transform  forever  the  field  of  human 
conflict?  Or  would  they  have  extolled  the  virtues  of  horse  cavalry, 
observation  balloons  and  the  bayonet? 

Much  of  the  tragedy  of  the  First  World  War  stemmed  from  the 
inability  of  the  military  leaders  of  the  day  to  grasp  the  implications  of 
change.  Their  failure  doomed  an  entire  generation  and  led  directly  to  a 
second,  even  more  destructive  global  war. 

It  is  our  responsibility,  that  of  each  and  every  one  of  us,  to  do  all  in 
our  power  to  see  that  we  are  ready  for  tomorrow,  that  we  never,  ever, 
allow  complacency  to  take  hold.  In  a  very  real  sense  that  is  why  you  are 
here.  And  make  no  mistake;  the  stakes  you  are  playing  for  remain  very  high 
indeed. 

What  will  the  future  look  like?  Almost  certainly  we  will  not  face  a 
hostile  superpower  in  the  near  term,  but  the  world  will  remain  a  dangerous 
place.  There  will  be  many  who  do  not  share  our  values,  many  who  will 
challenge  our  interests,  and  many  who  will  threaten  our  friends  and  allies. 
Some  of  these  threats  will  look  familiar.  The  nation-state,  after  all,  will  still 
be  with  us  for  a  long  time  to  come,  and  so  will  armies,  navies  and  air 
forces  much  as  we  know  them  today. 

But  the  21st  Century  will  also  see  the  non-state  actor  come  of  age. 
Fanned  by  the  ancient  flames  of  ethnic,  religious,  cultural,  and  economic 
rivalry,  many  groups  will  challenge  us  at  home  and  abroad.  However,  unlike 
past  eras,  terrorist  groups  and  other  non-state  actors  will  have  access  to 
state-of-the-art  technology.  They  will  have  secure  communications  and 
access  to  global  positioning  satellites,  highly  advanced  computer  technology 
and,  perhaps  most  frightening  of  all,  weapons  of  mass  destruction.  The 
proliferation  of  advanced  technology  with  military  applications  has  been  so 
rapid  and  so  pervasive  that  our  enemies  in  the  next  century  will  have 
capabilities  they  could  only  dream  about  in  this  one. 
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And  whether  those  enemies  come  in  the  form  of  nation-states,  or 
rogue  organizations  pursuing  their  own  agendas,  they  will  have  learned  to 
challenge  us  asymmetrically  —  not  where  we  are  strong,  but  where  they 
think  we  are  vulnerable. 

Thus,  preparing  to  respond  to  the  full  range  of  asymmetric  threats 
should  increasingly  occupy  our  interest,  our  time,  and  our  energy.  Now  is 
the  time  we  should  be  doing  that,  now  when  we  have  a  window  of 
opportunity,  when  we  don't  have  to  worry  about  a  strategic  rival  that  could 
threaten  our  existence  as  a  nation. 

Our  best  thinking  about  how  we  should  fight  in  the  21st  Century  is 
found  in  Joint  Vision  2010,  our  conceptual  template  for  future  joint 
operations.  Most  of  you  are  probably  familiar  with  JV2010,  at  least  in  its 
broad  outlines.  The  four  pillars  of  Joint  Vision  2010  are  its  key  operational 
concepts:  Dominant  Maneuver,  Precision  Engagement,  Focused  Logistics 
and  Full  Dimensional  Protection,  and  two  "enablers"  —  technological 
innovation  and  information  superiority.  Each  of  these  are  very  powerful 
individually,  but  they  are  not  ends  in  themselves. 

The  ultimate  goal  for  joint  warfighting  in  the  future  is  decisive 
operations:  the  ability  to  win  quickly  and  overwhelmingly  across  the  entire 
range  of  operations,  or  in  other  words.  Full  Spectrum  Dominance.  We 
want  our  men  and  women  to  be  the  masters  of  any  situation.  In  combat, 
we  do  not  want  a  fair  fight — we  want  capabilities  that  will  give  us  a  decisive 
advantage. 

Implications 

The  implications  of  Joint  Vision  2010  should  be  clear  for  us  in  the 
acquisition  community.  There  are  number  of  critical  enablers  that  are 
absolutely  essential  to  our  ability  to  shape  the  international  security 
environment  and  respond  to  the  full  spectrum  of  crises.  Two  of  those  are  of 
special  importance  to  us  here  today — ^harnessing  advanced,  complex 
technologies  to  achieve  the  desired  Revolution  in  Military  Affairs.  And 
reengineering  our  acquisition  process  to  meet  the  affordability  challenge 
through  a  Revolution  in  Business  Affairs. 

Technology  will  need  to  be  developed,  tested,  and  sustained  that  can 
profoundly  affect  the  warrior  and  leader  who  will  execute  2010  missions. 
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Exploiting  the  Revolution  in  Military  Affairs  involves  more  than  the 
acquisition  of  new  military  systems.  It  means  leaping  ahead 
technologically — not  creeping  ahead.  It  means  harnessing  these  new 
technologies  to  give  U.S.  forces  greater  military  capabilities  through  advanced 
concepts,  doctrine,  and  organizations  so  they  can  dominate  any  future 
battlefield.  And  it  means  more  than  ever  dealing  with  the  complexity  of  a 
systems  of  systems  approach. 

The  U.S.  military’s  modernization  effort  is  directly  linked  to  the 
broader  challenge  of  a  Revolution  in  Business  Affairs.  Efforts  to  reengineer 
the  Department’s  infrastructure  and  business  practices  must  parallel  the  work 
being  done  to  exploit  the  Revolution  in  Military  Affairs  if  the  nation  is  to 
afford  both  adequate  investment  in  preparations  for  the  future,  especially  a 
more  robust  modernization  program,  and  capabilities  sufficient  to  support  an 
ambitious  shaping  and  responding  strategy  through  2015. 

I  see  our  challenge  as  three-fold: 

1.  Conceiving,  designing,  developing,  testing,  producing,  fielding,  and 
supporting  complex  technologies  that  enable  our  new  warfighting 
concepts. 

2.  Doing  this  in  substantially  less  time.  Our  goal  is  to  reduce  cut  the 
time  from  concept  to  fielding  in  half! 

3.  And  doing  so  affordably — ^remarkable  reducing  not  just  the  cost  to 
acquire,  but  the  total  ownership  cost. 

Complexity 


The  nature  of  products  and  processes  demanded  by  today’s  global 
market  place  is  changing.  So  are  the  products  required  by  our  defense’s 
warfighters  and  strategies.  People  often  speak  of  the  past  as  being  a 
simpler  time.  We  frequently  emote  that  “things  were  not  nearly  as 
complicated.”  In  light  conversations,  we  “complain”  that  “back  then”  we 
didn’t  have  to  choose  between  paper  and  plastic,  regular  and  decaf,  or  even 
between  latte’  and  cappuccino. 

It  turns  out  that  those  conversations  are  not  among  persons  who  are 
imagining  things.  If  you  put  today’s  economy  under  a  microscope,  the  past 
really  was  a  simpler  time — at  least  from  a  product  and  process  point  of 
view.  A  recent  found  that  the  most  successful  commercial  technologies 
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have  changed  in  one  basic  way  over  the  past  quarter  century:  they  have 
become  more  complex. 

It  looked  at  the  30  most  valuable  exports  in  the  global  market  in  1970 
and  those  of  today.  They  found  in  1970  nearly  60  percent  of  the  world’s 
top  exports  were  essentially  simple  products  that  could  be  manufactured 
through  simple  processes.  Today,  that  same  percentage — 60  percent — of 
the  world’s  top  exports  are  complex  products  that  require  complex 
manufacturing  processes. 

For  example,  25  years  ago,  typewriters  were  one  of  the  top  products; 
now  its  PCs.  And  our  audio  players  that  were  based  on  Thomas  Edison’s 
phonograph  have  been  replaced  by  CD  players  that  rely  on  computer  chips 
and  lasers.  Certainly,  those  technologies  that  Joint  Vision  2010  will  rely  on- 
-low  observable  masking  technologies,  smarter  weapons,  long-range 
precision  capability  and  information  technologies — all  technologies  that  were 
unknown  a  quarter  century  ago—are  more  complex  than  those  of  25  years 
ago. 


Put  simply,  the  future  belongs  to  those  who  can  make  sense  of  the 
complex,  to  those  that  can  take  an  idea  from  conception  through  the 
functional  integration  of  many  complex  technologies  and  disciplines  to 
product  realization,  to  those  who  can  put  complex  technologies  and 
products  “out  the  door’’  and  into  the  hands  of  users. 

Today  I  will  address  five  specific  aspects  of  our  strategy  for  meeting 
the  RMA  and  RBA  that  I  believe  have  particularly  high  leverage  for  us: 

•  Integrated  Product  and  Process  Development 

•  Simulation  Based  Acquisition 

•  Improved  Software  Engineering 

•  Design  for  Ownership 

•  Open  Systems  Approach 

Integrated  Product  and  Process  Development 

Success  in  this  era  will  occur  when  different  approaches  and 
perspectives  are  brought  together.  The  final  value  added  is  always  greater 
than  the  sum  of  the  parts.  This  places  a  premium  on  qualities  that  we 
sometimes  undervalue  as  a  society:  qualities  like  diversity,  trust  and 
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community,  and  it  requires  that  we  develop  an  ability  to  bring  together  and 
reconcile  those  differing  perspectives  and  approaches. 

In  order  to  do  that,  the  Department  has  worked  to  find  the  best 
methods  for  reengineering  its  processes.  In  May  1995  the  Secretary  of 
Defense — then  Bill  Perry— directed  a  “fundamental  change  in  the  way  we 
acquire  goods  and  services”  and  mandated  that  the  concepts  of  Integrated 
Product  and  Process  Development  (IPPD)  and  Integrated  Product  Teams 
(IPTs)  “be  applied  throughout  the  acquisition  process  to  the  maximum 
extent  possible.” 

The  DoD  defines  IPPD  as  “a  management  process  that  integrates  all 
activities  from  product  concept  through  production/field  support,  using  a 
multifunctional  team,  to  simultaneously  optimize  the  product  and  its 
manufacturing  and  sustainment  processes  to  meet  cost  and  performance 
objectives.”  An  outgrowth  of  concurrent  engineering  practices,  the  IPPD 
process  reflects  a  systems  engineering  approach  that  has  incorporated 
sound  business  practices  and  commonsense  decision-making.  Fundamental 
to  the  successful  implementation  of  the  IPPD  concept  will  be  the 
willingness  of  organizations  to  undertake  and  experience  profound  changes 
in  their  cultures  and  past  practices. 

IPPD  has  had  many  successes  in  industry  and  it  fits  well  within  the 
spirit  of  the  Department’s  acquisition  reform  initiatives.  It  is  being 
accomplished  by  integrating  the  “functional  stovepipes,”  utilizing  best 
commercial  practices,  and  encouraging  teamwork  within  the  Department 
and  between  ourselves  and  industry. 

At  the  core  of  the  IPPD  implementation  are  Integrated  Product 
Teams  (IPTs)  that  organize  for  and  accomplish  tasks  that  acquire  goods 
and  services. 

IPPD  Key  Tenets 

To  implement  IPPD  effectively  it  has  been  important  for  us  to 
understand  the  interrelated  tenets  inherent  in  it. 

The  first  of  these  is  customer  focus.  The  primary  objective  of 
IPPD  is  to  identify  and  satisfy  the  customer’s  needs  better,  faster,  and  at 
less  cost.  The  customer’s  needs  should  determine  the  nature  of  the  product 
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and  its  associated  processes.  And  to  be  precise,  within  DoD  the  customer 
is  not  the  program  manager,  but  the  warfighter. 

A  second  tenet  is  that  processes  should  be  developed  concurrently 
with  the  products  they  support.  It  is  critical  that  the  processes  used  to 
manage,  develop,  manufacture,  verify,  test,  deploy,  operate,  support,  train 
people,  and  eventually  dispose  of  the  product  be  considered  during  product 
design  and  development.  Product  and  process  design  and  performance 
should  be  kept  in  balance  to  achieve  life-cycle  cost  and  effectiveness 
objectives.  Early  integration  of  design  elements  can  result  in  lower  costs  by 
requiring  fewer  costly  changes  late  in  the  development  process.  Early  and 
continuous  life  cycle  planning  is  essential. 

Third,  the  government’s  interface  with  industry  is  critical  to  IPPD 
success.  Our  requests  for  proposals  (RFPs)  and  contracts  should  provide 
maximum  flexibility  for  employment  of  IPPD  principles  and  use  of 
industry’s  processes  and  commercial  specifications,  standards,  and 
practices.  They  should  also  accommodate  changes  in  requirements  and 
incentivize  industry  to  challenge  requirements  and  offer  alternative  solutions 
which  provide  cost-effectiveness. 

Fourth  for  IPPD,  an  event  driven  scheduling  framework  should  be 
established  which  relates  program  events  to  their  associated 
accomplishments  and  accomplishment  criteria.  An  event  is  considered 
complete  only  when  the  accomplishments  associated  with  that  event  have 
reached  completion  as  measured  by  the  defined  criteria. 

Proactive  identification  and  management  of  cost,  schedule,  and 
technical  risk  is  fundamental.  Technical  and  business  performance 
measurement  plans,  with  appropriate  metrics,  should  be  developed  and 
compared  to  best-in-class  government  and  industry  benchmarks  to  provide 
continuing  verification  of  the  effectiveness  and  degree  of  anticipated  and 
actual  achievement  of  technical  and  business  parameters. 

Without  a  doubt,  the  most  essential  tenet  of  IPPD  is  multidisciplinary 
teamwork.  Inherently  IPPD  will  not  work  without  the  people  part,  which 
brings  us  back  to  the  diversity  issue  I  mentioned  earlier — previously 
separate  communities  working  together — for  common  objectives.  This  is 
teaming.  Integrated  Product  Teams  are  cross-functional  teams  that  are 
formed  for  the  specific  purpose  of  delivering  a  product  for  an  external  or 


7 


internal  customer.  IPT  members,  as  I  must  emphasize,  should  have 
complementary  skills  and  be  committed  to  a  common  purpose.  The  right 
people  at  the  right  place  at  the  right  time  are  required  to  make  timely 
decisions. 

Critical  to  the  formation  of  a  successful  IPT  are:  (1)  all  functional 
disciplines  influencing  the  product  throughout  its  lifetime  should  be 
represented  on  the  team;  (2)  a  clear  understanding  of  the  team’s  goals, 
responsibilities,  and  authority  should  be  established  among  the  business  unit 
manager,  program  and  functional  managers,  as  well  as  the  IPT ;  and  (3) 
identification  of  resource  requirements  such  as  staffing,  funding,  and 
facilities. 

Also  critical  is  empowerment.  Decisionmaking  should  be  driven  to 
the  lowest  possible  level  commensurate  with  risk.  The  team  should  be 
given  the  authority,  responsibility,  an  resources  to  manage  its  product  and 
its  risk  commensurate  with  the  team’s  capabilities.  The  authority  of  the 
team  members  needs  to  be  defined  and  understood  by  the  individual  team 
members.  The  team,  on  the  other  hand,  should  accept  responsibility  and  be 
held  accountable  for  the  results  of  its  efforts. 

I’ve  spoken  some  about  IPPD  as  a  process  and  some  about  people, 
but  let  me  shift  to  a  third  focus  area:  tools.  It  is  incumbent  on  both  DoD 
and  industry  to  employ  state-of-the-art  methods  and  tools,  to  become 
knowledgeable  of  the  capabilities  of  those  tools,  and  to  integrate  them  into 
their  internal  tools  sets  for  planning,  information  management,  design,  cost 
trade-off  analysis,  and  modeling  and  simulation. 

And  while  various  tools  are  important  I  would  like  to  draw  particular 
attention  to  virtual  prototyping  as  a  process  for  replacing  physical 
prototypes  by  computational  prototypes  which  can  be  embedded  in  realistic 
synthetic  environments  to  support  all  phases  of  IPPD.  This  we  are  calling 
Simulation  Based  Acquisition. 

Simulation  Based!  Acquisition  (SBA) 

The  Defense  Department,  in  cooperation  with  our  industry  partners, 
envisions  an  acquisition  process  enabled  by  the  robust,  collaborative  use  of 
simulation  technology  that  is  integrated  across  acquisition  phases  and 
programs.  The  objectives  of  Simulation  Based  Acquisition  (SBA)  are  to: 
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(1)  Substantially  reduce  the  time,  resources,  and  risk  associated  with  the 
acquisition  process; 

(2)  Increase  the  quality,  military  utility,  and  supportability  of  systems 
developed  and  fielded;  while  reducing  their  operating  and  sustaining 
costs,  and 

(3)  Enable  integrated  product  and  process  development  across  the  full 
acquisition  life  cycle. 

I  will  not  speak  long  on  SBA  since  I  know  it  will  be  addressed  in 
some  detail  later  this  morning,  but  let  me  just  state  that  I  am  convinced  that 
there  is  consistent  and  pervasive  evidence  already  accumulated  regarding 
the  value  of  a  simulation-based  approach  to  acquisition.  Both  commercial 
and  military  programs  provide  substantial  proof  of  tangible  results  that  can 
be  measured  in  terms  of  improvements  in  cost,  schedule,  productivity, 
and  quality/performance. 

It  is  clear  that  integrated  product  and  process  development,  backed 
by  a  strong  commitment  to  computer-based  modeling  and  simulation  tools, 
provides  a  dominant  and  competitive  edge  in  the  commercial  marketplace 
and  a  distinct  warfighting  advantage  on  the  battlefield. 

Software  Engineering  Improvement 

Let  me  turn  your  attention  now  to  an  area  of  powerful  leverage  for 
the  Department— software.  There  has  been  nothing  like  the  headlong  rush  to 
software  since  the  similar  rush  to  electronics  after  WWI.  The  average 
automobile  of  today  has  more  software  in  it  than  the  first  Apollo  spacecraft 
to  arrive  at  the  moon  30  years  ago. 

We  are  just  beginning  to  appreciate  that  a  new  breed  of  “knowledge 
warriors”  is  emerging — recognizing  that  knowledge  can  win,  or  prevent, 
wars.  And  this  is  causing  fundamental  changes  in  what  is  important  to  our 
warfighting  capability. 

In  the  Gulf  War,  television  cameras,  ravenous  for  dramatic  visuals, 
focused  on  F- 14s  roaring  off  the  decks  of  carriers,  Apache  helicopters 
swooping  over  the  desert,  MlAl  Abrams  tanks  growling  over  the  sands. 
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and  Tomahawk  missiles  singing  out  their  targets.  Pieces  of  hardware 
became  overnight  stars.  But  the  real  star  was  the  invisible  software  that 
processed,  analyzed,  and  distributed  data,  though  no  television  watcher  ever 
saw  those  who  produced  and  maintained  it — America’s  software  soldiers. 

Software  is  changing  military  balances  in  the  world.  Today  weapons 
systems  are  mounted  on  or  delivered  by  what  we  call  “platforms” — a 
missile,  a  plane,  a  ship,  or  even  a  truck.  And  what  we  are  learning  is  that 
cheap,  low-tech  platforms  that  are  operated  by  even  poor,  small  nations  can 
now  deliver  high-tech  smart  firepower — if  the  weapons  themselves  are 
equipped  with  smart  software.  Stupid  bombs  can  have  their  IQ  raised  by 
the  addition  of  retrofitted  components  dependent  on  software  for  their 
manufacture  or  operation. 

Costs  of  Software  Failure 

Information  or  knowledge  superiority  may  win  wars.  But  that 
superiority  is  exceedingly  fragile.  Pentagon  leaders  have  been  stunned  in 
recent  months,  both  by  learning  that  some  of  our  computer  systems  have 
been  tampered  with  by  hackers  and  by  a  recent  military  exercise.  Eligible 
Receiver,  that  demonstrated  how  easy  it  is  for  hackers  to  cripple  U.S. 
military  and  civilian  computer  networks. 

But  my  issue  for  you  here  today  is  not  so  much  one  of  information 
assurance — although  that  is  decidedly  a  top  priority  for  the  Department. 
Rather  I  want  you  to  focus  on  the  implication  that  you  succeed  or  fail  on 
the  software.  It  doesn’t  matter  how  much  speed,  or  how  much  stealth  or 
how  much  armor  plating  you  have;  you  won’t  succeed  if  the  software 
doesn’t  work. 

So  I  contend  that  software  that  does  not  work  is  self-inflicted 
information  warfare.  And  the  policies,  processes,  and  practices  that  guide 
the  development  and  use  of  information  technology  in  general,  and  software 
in  particular,  are  a  crucial  component  of  knowledge  strategy. 

Expectations 

Unfortunately  our  overall  track  record — or  the  perception 
thereof — for  producing  quality  software  is  underwhelming.  According  to 
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the  results  of  a  study  on  U.S.  software  development  reported  by  the 
Standish  Group  in  1996: 

•  In  1995,  only  16  percent  of  software  projects  were  expected  to 
finish  on  time  and  on  budget. 

•An  estimated  53  percent  of  projects  will  cost  nearly  190  percent  of 
their  original  estimates. 

•  Projects  completed  by  the  largest  American  organizations  have 
only  42  percent  of  the  originally  proposed  features  and  functions. 

This  sort  of  performance  record  might  somehow  be  adequate  in  a 
word  processor,  but  it  hardly  seems  acceptable  in  a  weapon  system  or 
where  safety  is  a  major  consideration.  After  all,  a  soldier  without  a  weapon 
is  at  best  a  tourist,  and  more  likely  a  target. 

Systems  Engineering  Process 

When  we  track  successful  software  developments,  almost  invariably 
the  accomplishment  can  be  linked  to  the  existence  of  a  good  systems 
engineering  processes.  It  is  for  this  reason  that  my  office  is  responsible 
for  software  acquisition  policy  in  the  Department.  Not  because  we  are  the 
focal  point  for  information  technology — because  we  aren’t.  Not  because 
we  are  the  office  of  primary  responsibility  for  software  tools  and 
technology — because  we  aren’t  either.  But  because  it  is  the  application  of 
the  disciplined  systems  engineering  process  that  makes  the  difference 
between  achieving  the  functionality  we  seek — in  both  hardware  and 
software. 

All  of  the  primary  systems  engineering  processes  must  come  together 
for  both  hardware  and  software  systems  development.  But  I  will  highlight 
two  specific  aspects  here:  Requirements  management  and  design  for 
sustainability. 

Requirements  Management 

I  have  a  cartoon  in  my  office  that  shows  two 
individuals — presumably  software  engineers — with  one  of  them  saying  to 
the  other  as  he  is  running  out,  “You  start  coding,  and  I’ll  go  find  out  what 
they  want.’’  Unfortunately  there  is  all  too  much  truth  in  this  picture. 
Because  what  is  being  developed  is  “only  software” — and  everyone  knows 


11 


software  is  easy  to  change — a  disciplined  requirements  management 
process  is  all  too  frequently  lacking.  Without  requirements  analysis  up 
front,  however,  the  results  are  unsatisfied  needs,  wasted  effort,  and 
rework. 

Software  may  be  easy  to  change — at  least  relative  to  bent  metal — but 
it  can  still  be  costly  in  both  time  and  dollars.  It  is  estimated  that  rework  is 
40  percent  of  the  cost  of  development.  Metrics  collected  by  Capers  Jones 
indicate  that  the  cost  and  schedule  impact  of  defects  in  requirements  are  the 
most  expensive  of  all  defects — followed  by  a  defect  in  top  level  design 
(architecture) ,  and  finally  by  defects  in  code. 

Design  for  Sustainment 

Much  of  the  software  that  is  operational  today  will  still  be  in  service 
several  years  from  now — with  large  implications  for  total  ownership  cost. 
By  way  of  example,  an  assessment  was  made  for  the  Air  Force  recently  of 
the  current  process  for  updating  the  software  in  major  operational  weapon 
systems.  Such  software  is  embodied  in  formally  designated  Operational 
Flight  Programs  (OFPs).  Over  the  service  life  of  software  intensive  aircraft 
and  smart  munitions  there  is  a  need  for  continuous  improvement, 
correction,  and  addition  of  new  capability  via  software  modification. 

Over  the  FYDP,  the  combined  B-1,  F-15,  and  F-16  programs  alone 
are  projected  to  spend  nearly  one  billion  dollars  on  OFPs.  When  the  planned 
expenditures  for  the  B-2,  F-22,  F-117,  and  the  advanced  weapons  are  added 
in,  the  total  five  years  costs  of  OFPs  is  nearly  two  billion  dollars. 

As  I  noted  earlier,  approximately  66  percent  of  DoD’s  software  costs 
are  associated  with  maintenance.  Almost  all  of  the  systems  engineering 
practices  that  have  high  leverage  for  lowering  the  cost  of  maintenance  are 
practices  that  need  to  be  implemented  during  development.  These  include 
development  practices  that  reduce  that  density  of  defects  in  the  software 
delivered  into  operation;  effective  software  test;  a  strong  configuration 
management  program;  and  taking  account  early  in  the  program  of  the 
engineering  environment  and  processes  that  need  to  be  in  place  for 
sustainment. 

Design  for  Ownership 
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Of  course,  software  is  not  the  only  component  of  systems  that  needs 
to  be  designed  with  sustainment  in  mind.  A  large  area  of  leverage  for  the 
Department  as  we  seek  to  reduce  the  total  cost  of  ownership  for  our 
systems  is  what  I  will  call  “Designing  for  Ownership.”  Let  me  explain. 

On  the  average,  ninety  percent  of  the  cost  of  owning  a  weapons 
system  is  determined  in  the  first  few  years  of  development — with  sixty  to 
eighty  percent  of  that  ownership  cost  being  operations  and  sustainment; 
Acquisition  costs — design,  test,  fabrication,... --are  really  only  a  relatively 
small  fraction  of  total  ownership  costs. 

Operations  costs  are  driven  by  things  like  consumables — fuel, 
ammunition — and  personnel,  a  large  cost  driver.  Support  costs  are  a  factor 
of  maintenance  labor,  repair  materials,  replenishment  spares,  and  the  like. 
These  are  all  factors  that  are  designed  into  the  system  we  will  own. 

This  is  one  of  the  reasons  why  acquisition  logistics  is  so  critical. 
Acquisition  logistics  is  multi-functional,  technical  management  discipline 
associated  with  the  design,  development,  test,  production,  fielding,  and 
sustainment,  and  improvement  of  systems.  Its  principal  objective  is 
ensuring  that  support  considerations  are  an  integral  part  of  the  system’s 
design  requirements,  that  the  system  can  be  cost-effectively  supported 
through  its  life  cycle,  and  that  the  infrastructure  elements  necessary  for  the 
initial  fielding  and  operational  support  of  the  system  are  identified  and 
developed  and  acquired. 

Acquisition  logistics  activities  are  the  most  effective  when  they  are 
integral  to  both  the  contractor’s  and  the  government’s  system  engineering 
technical  and  management  processes.  When  this  is  the  case,  system 
designers,  acquisition  logisticians,  and  program  managers  are  best  able  to 
identify,  consider,  and  tradeoff  support  considerations  with  other  system 
cost,  schedule  and  performance  parameters. 

The  Open  Systems  Approach  to  Weapons  System  Design 

Another  one  of  the  ways  we  can  design  with  life  cycle  considerations 
in  mind  is  the  open  systems  approach  to  weapons  system  design  which  is 
both  a  technical  approach  and  a  preferred  business  strategy  that  allows  DoD 
to  field  superior  combat  capability  quicker  and  at  a  more  affordable  cost. 
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The  open  systems  approach  defines  key  interfaces  for  a  system  (or 
piece  of  equipment)  being  developed.  Interfaces  generally  are  best  defined 
by  formal  consensus  (adopted  by  recognized  industry  standards  bodies) 
specifications  and  standards.  However,  commonly  accepted  (de  facto) 
specifications  and  standards  (both  company  proprietary  and  non¬ 
proprietary)  are  also  acceptable  if  they  facilitate  utilization  of  multiple 
suppliers. 

The  use  of  de  facto  specifications  and  standards  takes  advantage  of 
the  fact  that  firms,  particularly  those  in  the  commercial  arenas,  frequently 
develop  hardware,  software  and  systems  standards  of  the  design  and 
fabrication  of  computing,  telecommunications,  display,  sensing,  and  signal 
processing  systems.  Whether  interfaces  are  described  by  consensus  or  de 
facto  standards,  the  benefits  only  accrue  if  products  from  multiple  sources 
are  economically  possible.  Although  the  most  common  emphasis  is  on 
electronic  systems,  the  open  systems  approach  is  widely  applicable,  from 
fasteners  and  light  bulbs  to  jet  engines. 

An  open  systems  approach  is  designed  to  facilitate  the  use  of  widely 
accepted,  standard  products-from  multiple  suppliers-in  DoD  weapons 
systems.  In  addition,  if  the  architecture  is  defined  by  specifications  and 
standards  used  in  the  private  sector,  the  DoD  can  be  one  of  many 
customers  to  leverage  the  benefits  of  the  commercial  marketplace,  taking 
advantage  of  the  competitive  pressures  which  motivate  commercial 
companies  to  reduce  prices,  and  introduce  new  products  developed  with 
internal  resources. 

The  open  systems  approach  can  have  a  profound  effect  on  the  life- 
cycle  cost  of  a  system.  Program  managers  can  have  access  to  alternative 
sources  for  the  key  subsystems  and  components  to  construct  DoD 
systems.  DoD  investment  early  in  the  life-cycle  is  reduced  since  at  least 
some  of  the  required  subsystems  or  components  are  likely  to  already  be 
available,  or  being  developed  without  direct  DoD  investment.  Production 
sources  can  be  competitively  selected  from  multiple  competitors. 

The  system  design  flexibility  inherent  in  the  open  system  approach, 
and  the  more  widespread  availability  of  conforming  commercial  products, 
mitigates  potential  problems  associated  with  a  diminishing  defense- 
dependent  manufacturing  base.  Finally,  life-cycle  costs  are  reduced  by  a 
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long-lived,  standards  based  architecture  that  facilitates  upgrades  by 
incremental  technology  insertion,  rather  than  by  large  scale  system  redesign. 

The  system  architecture  should  be  addressed  early  in  a  program  to 
maximize  the  number  of  potential  solutions,  and  thereby  help  reduce 
program  cost.  By  developing  the  architecture  early  in  a  program,  the 
specific  technology  used  in  its  implementation  can  then  be  chosen  as  late 
as  possible. 

The  application  of  the  open  systems  approach  to  legacy  systems  is 
less  obvious  but  still  beneficial.  Legacy  systems  usually  have  size,  space, 
power,  cooling  and  shape  factor  constraints.  For  these  systems,  the  open 
systems  approach  can  provide  form-fit-function  interface  (F3I)  solutions 
within  existing  packaging,  power,  and  environmental  constraints.  In  such 
cases,  the  open  systems  solution  frequently  requires  less  system  resources 
by  using  newer,  more  efficient  technologies.  The  open  systems  approach  is 
similar  to  F3I  except  that  the  open  systems  approach  emphasizes  choosing 
interfaces  that  are  broadly  accepted  in  the  marketplace  to  allow  for  as  many 
suppliers  as  possible  over  the  long  term. 

Closing 


At  the  end  of  the  day  we  will  field  a  Joint  Force  of  unmatched 
capability  and  versatility.  How  good  will  we  be?  Let  me  paint  a  picture  for 
you. 


In  the  Joint  Force  of  2010,  we'll  be  able  to  detect  the  launch  of  a 
ballistic  missile,  identify,  target  and  attack  the  launch  platform,  alert  all  units 
in  the  impact  area,  and  attack  and  destroy  the  incoming  missile  all  in  a 
matter  of  a  very  few  seconds.  The  ability  to  transfer  information  that  fast, 
across  service  and  even  national  boundaries,  in  the  fog  and  friction  of  war, 
using  joint  language  that  we  all  understand,  will  be  nothing  less  than 
revolutionary. 

Most  of  you  are  probably  thinking  this  is  General  Shelton’s  job,  or 
Secretary  Cohen’s,  but  it's  really  not.  It's  your  job,  because  only  you  and 
your  counterparts  can  make  this  happen  on  the  battlefield.  I  expect  every 
acquisition  professional  to  be  part  of  the  team  making  our  national  strategy 
work — making  Joint  Vision  2010  a  reality.  Remember,  your  theme  is 
“meeting  the  technology  needs  of  the  warfighter  in  the  year  2000  and 
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beyond.”  Remember  also  that  our  challenges  include  not  only  meeting 
those  technology  needs,  but  doing  so  quickly  and  affordably. 

I  have  discussed  a  number  of  strategies  or  initiatives  that  I  believe  will 
contribute  to  engaging  those  challenges — IPPD,  Simulation  Based 
Acquisition,  improved  software  engineering,  designing  with  total  ownership 
in  mind,  and  open  systems  approaches.  Undoubtedly  these  strategies  and 
others  will  be  discussed  in  more  detail  here  this  week. 

Because  of  the  unprecedented  opportunities  and  challenges  emerging 
from  the  rapidly  changing  technologies  enveloping  us  today,  I  cannot 
emphasize  too  much  our  need  to  work  together  to  succeed.  We  must  rely 
on  each  other  now  more  than  ever  before. 

The  fact  that  our  economy,  and  indeed  our  way  of  life,  and  certainly 
our  defense,  is  now  shaped  and  dominated  by  technological  products  of 
inordinate  complexity  means  that  we  must  see  beyond  the  limits  of  our 
individual  perspectives  and  achieve  the  breakthroughs  that  occur  only 
through  the  synthesis  of  widely  different  skills  and  points  of  view.  True 
progress  within  an  envelop  of  complexity  occurs  only  through  an 
appreciation  of  mutual  benefit. 

Whatever  our  individual  challenges,  if  we  join  our  talents  and  work 
together,  we  can  and  will  meet  those  challenges. 

Many  of  the  discussions  on  the  agenda  for  this  symposium  will 
address  what  you  are  doing  to  “meet  the  technology  needs  of  the 
warfighter.”  Peter  Drucker  has  said  that  ours  is  a  world  in  which 
knowledge,  not  labor,  not  raw  materials,  not  capital,  but  knowledge,  is  the 
key  resource  .  This  meeting  is  your  opportunity  to  increase  your 
knowledge,  and  to  share  your  knowledge.  I  strongly  encourage  you  to  take 
the  maximum  advantage  of  this  opportunity. 
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